chore: reduce binary size with upx#212
Conversation
mdelapenya
added
chore
mdelapenya
requested review from
HofmeisterAn,
cristianrgreco,
eddumelendez and
kiview
kiview
left a comment
kiview
left a comment
There was a problem hiding this comment.
Do you have numbers on startup impact?
Context, I believe for normal users (i.e. not CI), smaller images are less important than fast startup times. Depends on the accumulated values, but my hunch is, we don't want to make this trade.
There was a problem hiding this comment.
I've let Copilot crunch the numbers on this in #213.
The TLDR is (which I admittedly might trust too blindly, but isn't that the name of the game nowadays? 😅):
UPX provides net benefits when:
(Pull Time Savings × Pulls) > (Startup Overhead × Starts)With 3.9 second pull savings vs 0.1ms startup overhead (100-iteration average), UPX is beneficial in virtually all real-world scenarios where containers are pulled more than once per 39,000 starts.
Given that we see Ryuk being pulled up to 19M times per month, we end up with real world savings of 95 TB per month!
Edit:
Above numbers don't consider savings we get on the bigger images, through HTTP transport compression 😉
2 participants
What does this PR do?
It uses upx to optimise the final Go binary.
I explored it on https://github.com/testcontainers/helloworld, and applied all the knowledge from that here.
Why is it important?
Instead of producing a Docker image with 10MB, we are producing one with ~5MB